1. Field of the Invention
The present invention relates to the fields of distributed computing systems, client-server computing and object oriented programming. Specifically, the present invention is a method and apparatus for providing program mechanisms which are independent of the operating system kernel, to handle inter-client communications involving objects. This continuation-in-part specifically relates to a particular type of mechanism for passing arguments between domains by use of a shared memory region in a way that provides an efficient and secure use of shared memory.
2. Background
A key problem in Operating Systems development and maintenance is permitting the introduction of new interfaces and implementation techniques in a way which allows clients and programmers maximum flexibility without loading the operating system down with implementation details. Moreover, this problem becomes more intense when developing object oriented operating systems which have micro-kernel architectures. Micro-kernels typically permit clients to implement complex sub-systems at the client level, such as file systems, for example. Nevertheless, basic system processes such as interclient or intercomputer communications are so complex that clients and object implementors should not be concerned with these processes. That is, these inherently "system" type processes are more efficiently done by standard modules, but should be handled in a way which does not require that the base operating system is constrained by these processes.
This disclosure describes a solution to this basic problem for systems which use the object metaphor to define the interfaces between different components of a system. An elegant solution is described which allows standard modules to handle communications of object calls between remote computers which may be sending other objects as parameters of the calls.
In an object oriented system, an object is a component comprising data and operations which can be invoked to manipulate the data. The operations are invoked on the object by sending calls to the object. Each object has an object type. The object type defines the operations that can be performed on objects of that type. The object operations are implemented independent of the objects themselves. Additionally, one object type may inherit the object operations defined and implemented for other object type. For further description of object oriented design and programming techniques: see "Object-oriented Software Construction" by Bertrand Meyer, Prentice-Hall 1988.
In client-server computing, typically there is a set of computers that can communicate with one another through a network connecting the computers. Some of these computers act as providers of services or functionality to other computers. The providers of such service or functionality are known as "servers", and the consumers of such service or functionality are called "clients". The client-server model also generalizes to the case where distinct programs running on the same computer are communicating with one another through some protected mechanism and are acting as providers and consumers of functionality.
In object oriented distributed systems based upon the client-server model, there exist servers that provide object oriented interfaces to their clients. These servers support objects consisting of data and the associated software. Clients may obtain access to these objects and may execute calls on them. These calls are transmitted to the server from the client. At the server these calls are executed via the software associated with the object. The results of these calls are then transmitted back to the client.
The object metaphor is a useful technique because it provides a separation between an object's interface and its implementation and because it permits multiple implementations of a single interface, which in a distributed system may reside on different machines. However, in existing object oriented systems the base system defines fundamental object properties such as what object "invocation" means, what it means to "pass an object as an argument", etc.
Unfortunately, by letting the base system define what the fundamental properties are, the base system is required to support all those fundamental properties that we wish objects to have. For example, assume that we wish to support object replication so as to increase reliability. It is not desirable for client application code to do extra work in order to talk to replicated objects. Therefore it would be preferable to support replication by the system. But there are lots of ways of implementing replication. The question is does one build some of these ways into the base system and reject the others? If an application developer discovers a more efficient way of managing replicated objects within his application then it would be desirable for him to be able to use his new mechanism without having to change the base mechanism. Moreover, while the base system could be used to support some standard base mechanisms for particular properties such as replication, persistence, crash recovery, and caching, this seems to pose two dangers. First, it may make simple object invocation expensive, even for those objects that do not desire the expensive properties. Secondly, it makes it difficult for third parties to add new properties that are peculiar to their particular needs.
Accordingly, what is needed is a method to provide control of the basic mechanisms of object invocation and argument passing that are most important in distributed systems, wherein the method is implemented by some scheme which is separated from object interfaces and object implementations.
Techniques for providing a language-level veneer for remote operations (for example, "Remote Procedure Calls") have been in use for many years. Typically these take the form that a remote interface is defined in some language. Then a pair of stubs are generated from this interface. The client stub runs in one machine and presents a language level interface that is derived from the remote interface. The server stub runs in some other machine and invokes a language-level interface that is derived from the remote interface. Referring now to FIG. 1, to perform a remote operation, a client application 12 on one machine 10, invokes the client stub 14, which marshals the arguments associated with the invocation into network buffer(s) and transmits them to the server stub 22 on the remote machine 18, which unmarshals the arguments from the network buffer(s)and calls the server application 24. Similarly, when the server application 24 returns a response, the results are marshaled up by the server stub 22 and returned to the client stub 14, which unmarshals the results and returns them to the client application 12. The entire mechanics of argument and result transmission, and of remote object invocation, are performed in the stubs. Both the client application and the server application merely deal in terms of conventional language-level interfaces.
When the arguments or results are simple values such as integers or swings, the business of marshaling and uumarshaling is reasonably straightforward. The stubs will normally simply put the literal value of the argument into the network buffer. However, in languages that support either abstract data types or objects, marshalling becomes significantly more complex. One solution is for stubs to marshall the internal data structures of the object and then to unmarshal this data back into a new object. This has several serious deficiencies. First, it is a violation of the "abstraction" principle of object-oriented programming, since stubs have no business knowing about the internals of objects. Second, it requires that the server and the client implementations of the object use the same internal layout for their data structures. Third, it may involve marshalling large amounts of unnecessary data since not all of the internal state of the object may really need to be transmitted to the other machine. An alternative solution is that when an object is marshalled, none of its internal state is transmitted. Instead an identifying token is generated for the object and this token is transmitted. For example in the Eden system, objects are assigned names and when an object is marshalled then its name rather than its actual representation is marshalled. Subsequently when remote machines wish to operate on this object, they must use the name to locate the original site of the object and transmit their invocations to that site. This mechanism is appropriate for heavyweight objects, such as fries or databases, but it is often inappropriate for lightweight abstractions, such as an object representing a cartesian coordinate pair, where it would have been better to marshal the real state of the object. Finally, some object-oriented programming systems provide the means for an object implementation to control how its arguments are marshalled and unmarshalled. For example, in the Argus system object implementors can provide functions to map between their internal representation and a specific, concrete, external representation. The Argus stubs will invoke the appropriate mapping functions when marshalling and unmarshaling objects so that it is the external representation rather than any particular internal representation that is transmitted. These different solutions all either impose a single standard marshalling policy for all objects, or require that individual object implementors take responsibility for the details of marshalling.
Within object-oriented languages, the technique of reflection permits object implementors to gain control of some of the fundamental object mechanisms. [See "Reflective Facilities in Smalltalk-80," by Brian Foote & Ralph E. Johnson 1989, OOPSLA '89 Proceedings, pages 327-335]. Very simply, a reflective system is one which incorporates structures representing aspects of itself, and reflective computation is a system's computations about itself.
For example in the 3-KRS language, objects can have meta-objects associated with them. A meta-object provides methods specifying how an object inherits information, how an object is printed, how objects are created, how message passing (that is, object invocation) is implemented, etc. 3-KRS does not however provide any control over argument passing.
By providing reflective object invocation in Smalltalk-80 it was possible to implement objects which are automatically locked during invocation and objects which only compute a value when they are first read.
However while reflection has been used within a single address space, there has been no attempt to apply it specifically to the problems of distributed computing.
Accordingly, the present invention provides an apparatus and a method comprising a logic module, called a sub-contract, that has been designed to provide control of the basic mechanisms of object invocation and argument passing that are most important in distributed systems, in a way which makes it easy for object implementors to select and use an existing sub-contract, and which permits the application programmers to be unaware of the specific sub-contracts that are being used for particular objects.
More specifically, this continuation-in-part provides a shared-memory subcontract mechanism to securely and efficiently pass arguments by means of a shared memory region, which would be especially appropriate when the particular hardware configuration on which the client and server are running permits. Such as where the client and server are on the same machine, or same multiprocessor unit, or even in some local area networks (LANs). The prior art describes a "Lightweight Remote Procedure Call CLRPC") communication facility which was integrated into the TAOS operating system of the Digital Equipment Corporation SRC Firefly multiprocessor workstation. (See the paper titled "Lightweight Remote Procedure Call" by Brian N. Betshad, Thomas E. Anderson, Edward D. Lazowska and Henry M. Levy, Department of Computer Science, University of Washington, Seattle, Wash., published by the Association for Computing Machinery, 1989 (document # ACM 089791-338-3/89/0012/0102 pages 102-113).) However, this LRPC facility was directed to a kernel controlled mechanism specifically, addressing the case of same-machine communication wherein only small, simple arguments are passed, wherein the kernel is required to create a binding between a client and a server and thereafter the kernel is involved in allocating the shared-memory regions (called A-stacks) and in checking the validity of A-stacks during object invocation. The present invention does not invoke the kernel in the shared-memory process, requiring no kernel memory and requiring a smaller number of door or channel identifiers. Arguments which are passed are not restricted to "only small, simple arguments" changing or modifying the shared-memory process, or adding a different shared-memory process does not require any modification to the kernel.